Reconfiguration of a Distributed Information Fusion System 
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Abstract 

Information Fusion Systems are now widely used in 
different fusion contexts, like scientific processing, sen- 
sor networks, video and image processing. One of the 
current trends in this area is to cope with distributed 
systems. In this context, we have defined and im- 
plemented a Dynamic Distributed Information Fusion 
System runtime model. It allows us to cope with dy- 
namic execution supports while trying to maintain the 
functionalities of a given Dynamic Distributed Infor- 
mation Fusion System. The paper presents our system, 
the reconfiguration problems we are faced with and our 
solutions. 

keywords Availability, Data fusion, Decision mak- 
ing, Discrete-event dynamic systems, Performance 
evaluation, Run-time systems. 

1 Introduction 

The aim of an Information Fusion System is to compute 
results of higher quality (with respect to some criteria 
to be defined) from information provided to it either 
from the "real world" (sensor networks) or from com- 
puter sources (databases for instance). Present IFS are 
frequently distributed since data sources or/and com- 
putation resources power are actually distributed. 

Computer based Information Fusion Systems are 
widely diffused since a couple of decades (see for in- 
stance [ |MB971lKZK97] ]). Although there are already 
a lot of solutions to develop and to deploy Distributed 
Information Fusion Systems (DIFS), see [ [HMM + 07| ] 
for a survey of solutions in the sensor network area for 
instance, most of them are restricted to specific appli- 
cation areas. Moreover, they frequently assume that 
the execution support system is fixed. 



The goal of our project is to define a runtime frame- 
work for Dynamic Distributed Information Fusion Sys- 
tem (DDIFS). This framework is based on a model of 
the Fusion Process (FP) and on a model of its derived 
run-time deployment. These two models allow us to 
control the DDIFS: 

• the system restores a correct state after a run-time 
error; 

• the system modifies itself when it detects that a 
better configuration, in a sense to be detailed, 
could be deployed. 

These two adaptive behaviours explain why our sys- 
tems are termed Controlled Dynamic Distributed In- 
formation Fusion Systems (CDDIFS). 

Fusion methods can be classified [ |Sas02j ] into three 
groups, according to their domain: probabilistic mod- 
els such as Bayesian networks [[MDW06J], approxima- 
tion methods which update a model of the environment 
and take decisions based on the predicted next state 
(for example Kalman filters [[SL06J]) and interpolation 
methods such as fuzzy logic approaches [[BGM03J] and 
neural networks [[PC03J]. 

In our context, an Information Fusion Process (IFP) 
is defined as a discrete data-flow graph the nodes of 
which are fusion functions and the edges of which are 
links between function ports. Ports of a fusion node are 
connected to input, output and parameters of the fu- 
sion function. A fusion function / computes a tuple of 
output values Y = (yi, yx) from a tuple of input val- 
ues X = (x\, xj), for a given vector 9 = (Q\,...,6j) 
of parameters: 

(yi,-,yK) = f(o u ...,oj)( x u-> x i)- 

Distinction between input and parameter values comes 
from the fact that an input value is used for only one 
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computation of the outputs, while a parameter is a 
sustained value, used for each computation, until it 
is modified. Our model is termed discrete since the 
tuples are discrete data and each function "consumes" 
one input tuple and produces one output tuple. 

Our approach terms Information Fusion System 
(IFS) a hardware and software environment used to im- 
plement an IFP. It includes all the components needed 
to execute the fusion function implementations and to 
transfer information between the functions. The dis- 
tributed aspect comes from the physical distribution 
of the run-time elements of the IFS: sensors, devices, 
computers, smart-phones, etc., are actually usually dis- 
tributed. We call execution framework (EF) the com- 
putation environment where implementations of fusion 
nodes run (see section [3]) . 

Our model deals with dynamicity in the sense that 
it copes with possible modifications of the IFS at run- 
time. Modifications may be the update of a fusion node 
implementation, the modification of network connec- 
tions between the EFs or the failure of a part of the 
IFS. Note that however in this paper, it is assumed 
that the IFP is fixed. 

The paper is organised as follows. The next sec- 
tion explains how we control the IFS. Section [3] de- 
tails our current implementation, while in section [H we 
present the reconfiguration strategies we have designed 
and their implementation. An application example is 
detailed in section and we indicate work in progress 
in section [6l 

2 Control of DDIFS 

Figure Q] presents the two levels view architecture of 
our proposal: 

• the fusion graph, i.e. the fusion nodes (or fusion 
functions) and the connections between their input 
and output ports; 

• the assignment of the fusion functions to the ele- 
ments of the fusion run-time system. 

The run-time DDIFS is controlled for what concerns 
error recovery and quality improvement. 

Our system is developed in such a way that it checks 
for the IFS consistency i.e. the availability of the com- 
munication network between runtime sub-systems and 
the availability of these sub-systems. To this end, soft- 
ware sensors installed into the system provide both 
quantitative and qualitative measurements. The time 
interval between two executions of a fusion function or 
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Figure 2: Implementation details - Runtime frame- 
works hierarchy. 

the amount of data present in some point of the sys- 
tem are such measurements. Thanks to these software 
sensors, errors and failures are detected and the system 
updates itself by changing its configuration in order to 
correct them. 

The quality improvement is based on a General- 
ized Stochastic Petri Net (GSPN) [ |MBD98j ] model 
of the configuration. We build a GSPN of the run- 
time system from which we derive a set of perfor- 
mance/dependability steady-state rewards (r n )i< n <jv. 
These rewards (CPU utilisation, response times, etc.) 
are computed from the Markov chain underlying the 
GSPN, with a tool, like GreatSPN [ [CFGR95] ] running 
on one of the host systems of the IFS. Details of the 
performance analysis of our system will be presented in 
a future paper. In short, we build a total order between 
configurations based on the rewards (r n ). 

3 Implementation 

To take into account modern architectures, our model 
distinguishes four hierarchical levels in an IFS (Fig- 
ure [2]) . The lowest level is the physical machine level 
such as a Personal Computer, a smart-phone, etc. Each 
machine supports one or several host operating systems 
(as in virtualised systems). On top of a given host, an 
EF defines the fundamental architectural element of 
our IFS, assuming that every EF owns a unique (IP 
address, port number) pair. Each EF hosts the two 
sub-systems of our solution: an execution sub-system 
and a control sub-system. 

The intend of our system is to take advantage of 
the skills of both information fusion experts and de- 
velopers. Thus while the (information fusion) designer 
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Figure 1: Information Fusion Process (IFP) - Information Fusion System (IFS) relationship 



defines the data-flow graph that represents the fusion 
process through a graphical interface, developers may 
implement the execution codes of the fusion functions. 
In this way, the designer expresses specifications on 
the fusion process, and the developer only writes the 
selected fusion method Both do not take care about 
the deployment nor the modifications of the run-time 
system. 

An implementation of the FP, also termed as a con- 
figuration, is defined by the choice of all the imple- 
mentation elements translating the FP: fusion node 
implementations (see below), assignment of the fusion 
nodes to EF (a fusion node is assigned to one EF), 
ports links mapping between fusion nodes. It assumes 
that EFs are linked through an undirected connected 
IP network (the execution graph) and that all the con- 
nections between fusion node ports are carried by this 
network (N) . If the output yk of a function / assigned 
to the EF e is the input x% of /' assigned to e', then the 
configuration defines the path between e and e' in N . 
This path may use intermediate EF only used to con- 
nect the source and the destination EFs. As soon as 
a configuration is defined, it is deployed by the control 
sub-systems of the EFs. 

An execution sub-system manages the execution el- 
ements corresponding to fusion nodes. In contrast, a 



control sub-system manages the execution sub-system: 
monitoring and analysis of the FP execution and re- 
configurations of the IFS. 

3.1 Fusion Node implementation 

At the fusion process level, a fusion node consists of 
three sets of ports (inputs, parameters, outputs) and a 
mathematical description of the fusion function. Our 
model assumes that at least one implementation of each 
fusion function is available in the system and that all 
the implementations are valid i.e. they conform to their 
mathematical specification. To manage the execution 
of a fusion node related tasks, we introduce a fusion 
node container (Figure [3]). It controls the implementa- 
tion of the fusion function, termed the execution entity; 
it updates the value of the control parameters, and it 
transfers the software sensors values to the rest of the 
control system. 

3.2 Execution mechanism 

Implementation of the input port discrete semantics is 
based on queues storing discrete data, one queue being 
bound to each input port of a fusion node. Each com- 
putation of the fusion function un-queues one data item 
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Figure 3: Implementation details - Fusion node imple- 
mentation. 

of each queue and uses the latched values of the param- 
eters. Moreover, according to the Best effort policy 
defined in Section [4.31 the system tries not to lose data 
when unreachable fusion nodes are detected. Hence, 
the execution of the fusion function is started iff the 
following conditions are satisfied: 

• no input queue is empty; 

• the result of the computation may be sent to all 
its consumers. 

The first condition is required to provide a value of 
each input port to the execution entity. The second 
condition is a design decision: we do not start a com- 
putation of the fusion function if we are not sure (to 
the best of our knowledge!) that the results could be 
processed by their receivers. 

3.3 Implementation details 

An implementation of our project is already deployed 
in order to experiment our results and was used to run 
a video conference smart-room [ [WTS+08] ]. 

The current version of our system is deployed over 
OSGi [ |OSG05j ] platforms [ |RAR07j ] linked by stan- 
dard networks (LAN, Wi-Fi, Bluetooth). EFs are im- 
plemented as OSGi platforms and are linked together 
by R-OSGi services. The sub-systems are presently 
implemented as bundles, respectively for the control 
and the execution sub-systems, installed and started 



4.1 Reconfiguration setup 

The reconfiguration of the system is twofold: correc- 
tion of a configuration in order to restore the fusion 
process after an execution failure or an execution er- 
ror, or improvement of the current configuration. The 
possible modification of a configuration relates to fu- 
sion function implementations, function assignments to 
EF or to input-output ports link mappings. 

4.1.1 Configuration errors and failures 

The system is said to be in a failure state [[ALRL04J] 
when one of its outputs cannot produce a result. Such 
a failure derives from an error. Our system tries to 
avoid as much as possible system failures, by detecting 
errors before they lead to failures. We detect two kinds 
of error: 

• Inter-execution framework errors: an EF disap- 
pears or a communication channel is broken; 

• Intra-execution framework errors: errors due to 
fusion node interactions (i.e. deadlock) and in- 
ternal fusion node errors (for instance arithmetic 
overflow, time-out). 

As mentioned in Section software sensors, mostly 
throwing a Java exception, are used to detect these 
errors. Inter-execution framework errors are detected 
through monitoring of the communication links with 
programmed acknowledgments. Intra-execution frame- 
work errors throw Java exceptions caught by the con- 
trol system of the execution framework. 
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4.1.2 Configuration improvement 

Even if there is no error, the control system tries to 
improve the runtime system permanently. To this end, 
firstly the control system periodically senses the model 
parameters from the execution system and computes 
the rewards associated to the model. If a significant 
variation is stated between two or more computations, 
the control system triggers a search for a new, and 
hopefully "better", configuration. Secondly, the con- 
trol system also launches a new configuration search 
when it detects a variation in the available runtime en- 
vironment, for example due to a new available EF. 

4.2 Selection of a new configuration 

As soon as the need for a reconfiguration is launched, 
the system has to search for a new configuration. The 
search algorithm takes the description of the IFP and 
the constraints between the fusion nodes and the EFs 
as inputs. In fact, the selection of a new configuration 
due to reconfiguration involves the same steps as the 
initial configuration selection. 

The search is based on a Constraint Program- 
ming approach already proposed by several re- 
searchers [ [ZSB+081 IAWHK07] ] in the context of the 
application component placement problem [[KIK03]]. 
The IFP provides a set of constraints such as the set 
of fusion nodes, the required links between output and 
input fusion nodes. The IFS constraints the possible 
configurations in several ways: 

• each fusion function can be deployed on a subset 
only of the EF; 

• connections between EF are fixed and given 
through an execution graph. We call "channel" 
a direct connection between two EF e and e'. 

• for a given link / between and x' i: we must se- 
lect a chain ((e m , e m +i))i< m <M of channels in the 
execution graph such that e\ = e and ej^+i = e'. 

• a given EF must have enough memory resources 
to be able to run the fusion functions assigned to 
it. 

Hence, for a given assignment of fusion nodes to EF 
together with the paths in the execution graph derived 
from links between fusion nodes, we are able to express 
automatically a set of constraints on these assignments. 

There are in general several paths in the execution 
graph. For each path, we can define a "cost" based 
for instance on the number of its channels , i.e. its 
"length", an effective usage cost, etc. We assume that 



all links from / to /' use the same path in the execu- 
tion graph. Although we have designed our search in 
a generic cost way, in the present work we have im- 
plemented only the "length cost". We then fix the 
"best" path as the shortest path (in the cost mean- 
ing) in the execution graph between the EF of the 
linked fusion nodes. These shortest paths between EF 
are pre-computed for a given IFS with the Floyd-Roy- 
Warshall algorithm (see for instance [[CLRS01]] and 
they are used by the Constraint Satisfaction Problem 
(CSP) solver. The CSP is now well defined and its 
variables are the assignments of fusion functions to the 
EF. 

We can also add an optimisation criterium to the 
previous CSP to take into account the two antagonistic 
properties of a configuration: 

• global maximal usage of the set of EFs: deploy the 
fusion nodes on as much as possible EF; 

• global "short" physical communication between 
output and input fusion functions: deploy linked 
fusion functions on "neighbouring" EFs. 

To do so, we define a generic cost function C of a con- 
figuration: C = h{Cdi C c ) where Cd is a cost associated 
to the assignment of the fusion functions, and C c is a 
cost associated to the mapping of the links to the chan- 
nel chains and h a composition function. Note that Cd 
should be increasing with the "density" of the fusion 
functions on the EF. For instance, Cd could be: 

Cd = max{n(e)} — min{n(e)} 

eeE e£E 

with n(e) being the number of fusion functions assigned 
to the node e and E the set of EFs. For C c we can take 
a weighed (a u ) sum of the number of used channels: 

C C =Y^ a u n(u) 

where n(u) is the number of links (between fusion func- 
tion ports) using the channel u and U is the set of 
channels of the execution graph. C c should also be in- 
creasing with the "distribution" of the fusion functions 
in the IFS. 

Finally, we send the problem to a CSP - with 
optimization- solver to get the configuration. 
We used the Choco solver which is available at 
|http : //www . emn . f r/ x-T nf o/ choco-solver/ doku . php, 
For the moment, the solver is run on one of several EF 
defined in a configuration file of the system. 
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4.2.1 Error recovery 

In the case of an error recovery, the control system 
selects as soon as possible a configuration compatible 
with the available resources. Hence, the search algo- 
rithm selects the first admissible configuration. Search- 
ing for a better configuration is performed during the 
next configuration improvement step. 

4.2.2 Configuration improvement 

In this case, the control system searches for another 
"significantly better" configuration. To this end, from 
the current configuration, it derives a model of the con- 
figuration and computes its rewards as explained in 
Section [2j Then it throws a search for a new configu- 
ration as a CSP with an optimisation based on com- 
parison of the rewards. 

4.3 Transition between configurations 

Independently from the reconfiguration strategy, the 
system applies the new configuration NC from the cur- 
rent configuration CC as follows. The system updates 
the location of the fusion node implementations, in case 
of new function assignments, and/or updates the exe- 
cution entities, in case of implementation swaps. In 
both cases the system behaves according to a best ef- 
fort policy. 

4.3.1 Best effort 

The system tries to prevent loss of data-flow driven in- 
formation present in it and already partially processed. 
To do so it is assumed that two different implementa- 
tions of the same fusion function have the same se- 
mantics in the IFP. Thus, input data of a fusion node 
may come from computations ran in any configuration 
without invalidating the next produced results. 

Let e' (in NC) be an updated version of the EF e 
(in CC). If e' can restore some data from the state 
of e, for instance by swapping an implementation of a 
fusion function, data waiting in the input queues are 
processed by the new execution entities. Hence there 
is no loss of data in this case. 

On the contrary, partially processed data present on 
e are lost in case of assignments of the fusion functions 
of e to an EF different from el . In such a reconfig- 
uration, the links between the functions are mapped 
into new paths according to the new location of the fu- 
sion node containers. Each fusion node container, and 
therefore its data, is destroyed on e and instantiated 
on new EFs with empty input queues. 




Figure 4: Passer-by example of reconfiguration - archi- 
tecture view. 

The current transition mechanism can be extended 
in order to cope special properties such as synchroniza- 
tion. In such and only when partially processed 
data are lost during the transition, some remaining 
data present in other EFs may be out of synchroniza- 
tion. To deal with this property, two extensions have to 
be added to our model: a label linked to the data that 
identifies the synchronization criterium, i.e. the time of 
sensors read, and a control element that deletes a data 
which is out of synchronization after a transition. Syn- 
chronization mechanism is presently not implemented 
in our system but is already defined in our model. 

5 Application example 
5.1 Passer-by example 

In the passer-by example (Figures H] and [5]) the com- 
puters respectively located in rooml and room2 display 
two videos. The first one is the original view of the 
user's head (taken from a smart-phone). The second one 
is a filtered view of the original view, and the selected 
filter is chosen by the user through a touch-pad. In the 
first configuration (ti) the user is in the rooml and his 
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Figure 5: Passer-by example of reconfiguration - pro- 
cess view. 

smart-phone produces a video of his head. The video 
is processed by powerful computers located in room3 
and the two videos are both displayed on the screen 
in rooml. While the user is moving between the two 
rooms, the system detects that the connection with the 
smart-phone is lost and tries to reconfigure itself. As 
soon as the communication is restored with the smart- 
phone, the second configuration (£2) executes the same 
fusion process but the last functions are assigned to the 
second computer in room2. 



6 Conclusion 

In this paper, we have presented problems raised by 
reconfiguration features of a runtime model for con- 
trolled dynamic distributed information fusion system 
(CDDIFS). Dynamicity comes from the changing run- 
time support of our systems. Reconfiguring a CDDIFS 
system means either correcting it because of an error or 
a failure, or else increasing its quality of service. Our 
proposal is based on several functional components: - 
monitoring of the networked run-time system provid- 
ing indication on the availability of the sub-systems 
and raw performance measures; - computation of a de- 
pendability model of the configurations running the 
Distributed Information Fusion System. - definition 
of a Constraint Satisfaction Problem (CSP) modeling 
the placement of the fusion functions onto the Execu- 
tion Framework; We take advantage of efficient solvers 
for both computation of performance indices (rewards) 
based on the dependability model and resolution of the 
CSP. We are hence able to reconfigure in the "best 
way" with respect to a given set of criteria, our CD- 
DIFS. Future work will deal first with full automation 
of all the components of our framework and instal- 
lation of the system on top of other middleware sys- 
tems like networked J2EE servers. We are also testing 
our framework with several kinds of Information Fu- 
sion Processes such as scientific computation systems, 



energy control systems, mechatronic systems. 
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